fix(super-editor): stop export from stripping tracked marks off the caller's tree - #3949

What

Once a header (or footer) sub-editor exists, the first exportDocx() writes the part's imported w:ins/w:del correctly and every later export writes it with the tracked changes gone — text inside a w:del comes back as an ordinary run, so a counterparty's tracked deletion silently becomes accepted content on the second save, with no user edit involved (#3893).

Mechanism

The w:ins/w:del decoders (v3/handlers/w/ins/ins-translator.js, v3/handlers/w/del/del-translator.js) removed the tracked-change mark by assigning the filtered marks array back onto the node they were handed:

node.marks = marks.filter((m) => m.type !== 'trackInsert');

That node belongs to the caller. The body path never notices because it starts from a fresh getUpdatedJson() snapshot each export, but #exportProcessHeadersFooters passes the converter's persistent import-time tree (this.headers[id] / this.footers[id]) by reference once a sub-editor is registered — which happens as soon as a user clicks into the header. Export 1 strips the marks off that tree permanently; export 2 re-serializes the already-stripped tree.

Fix

Strip the mark on a shallow copy of the node instead ({ ...node, marks: filtered }), leaving the caller's tree intact. This fixes the root cause for every exportToXmlJson caller, including the header-footer-sync fallback path that also passes the persistent tree by reference — repeated exports with no intervening edit now produce the same tracked changes every time. These two assignments are the only in-place mutations of caller data on the export path (audited node.marks = / node.attrs = / splice sites in the decode chain).

Testing

• New integration regression: headerTrackedChangesDoubleExport.test.js with a synthetic fixture (header-tracked-changes.docx, derived from the in-tree header-alternating-odd-even.docx with one w:ins + one w:del spliced into word/header1.xml). It registers a header sub-editor the way HeaderFooterEditorManager does, exports twice, and asserts word/header1.xml still carries ins=1 del=1 on the second export. Red without the fix (second export drops to ins=0 del=0, exactly the issue's output), green with it.
• New unit tests in both translator suites assert decode leaves the caller's marks untouched while the stripped copy is what reaches exportSchemaToJson.
• Full import-export + super-converter suites: 3643/3643 pass.

Fixes #3893